A cascaded FC configuration is one where the source disk of one map is the target disk of another map. For example, there may be one map defined with source disk A and target disk B, and another map defined with source disk B and target disk C. The cascade would include the three disks A, B and C and the two maps.
Current implementations of FC do not allow maps to be started when the FC target disk is an active source disk of another FC map. This means that the user either has to wait for the first map to complete before the second map can be started, or the first map has to be stopped before the second map can be started. In the former case, it can take a very long time (depending on, among other things, the size of the disks in the FC map and the rate at which the data is being copied) for the FC map to complete which is not ideal and/or may not be desirable. In the latter case, stopping the FC map results in an incomplete first copy, which may not be desirable.
An exemplary scenario illustrating this behavior on FC maps A→B and B→C can be demonstrated as follows: A→B is started and completes before B→C is started (e.g., because it is an incremental map). However, if and/or when B→C is started, A→B cannot be restarted until B→C completes (i.e., when C is independent of B). In an environment where multiple snapshots of a set of data are being taken, for example, for running simulations against and for backing up data after the simulation has run, this situation can frequently occur.
A disk in an FC map is said to be dependent on one or more other disks when it does not hold a complete copy of the data itself that it is presenting to the user. If this disk receives a read request for data that it does not hold, then it redirects the read to whichever other disk does hold this data. Conversely, a disk is said to be independent when it holds a complete image of the data that is presenting to the user. It can satisfy all read requests itself without needing to redirect the request elsewhere.
Another problem with cascaded FC relates to the behavior of a cascade when a FC map has an independent target disk image, but that target is a source for other maps. There are two ways of manipulating the cascade when this occurs.
In one or the first case, the target disk can be removed from the cascade once all downstream disks are independent of the target. That is, in the case of a cascade of A→B→C→D, if B becomes independent of A, and C is not dependent on B, then one can modify the cascade to achieve A→C→D. This approach allows the FC map A→B to be restarted, but leaves C dependent on A. This does not seem natural for a FC map which the user created from B to C. Note that the user would not be able to delete disk A even though the only map that contained this disk is now complete.
In another or the second case, the source disk can be removed from the cascade because the target no longer requires its source disk in order to maintain the image presented to the host. That is, in the case of a cascade A→B→C→D, if B becomes independent of A, then A can be dropped from the cascade leaving B→C→D. This approach appears more natural to the user and does not require the user to wait for C to become independent of B. However, without the invention, it also means that the map A→B cannot be restarted until C is independent of B.
All these situations greatly reduce the usability of cascade FC implementations. Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.